Preamble
The Request-Response system is the subsystem of GeoServer which deals with communication with the outside world. Before jumping in lets define some terminology in which we can use to define what the subsystem does.
A Service is a component running inside of GeoServer which performs tasks on behalf of a client. Examples include Web Map Service (WMS), and Web Feature Service (WFS).
A service expsoses a set of Operations to the outside world. An operation is a specific task that the service can perform on behalf of a client. Examples include GetCapabilities,GetFeature, etc...
A Request is the process of calling an operation of a service. A Response is the result of the request.
The responsibilities of the Request-Response system include:
- Handling incoming requests from clients
- Routing incoming requests to the appropriate service
- Forwarding response from service back to client
The following diagram depicts the workflow:
Design
The following class diagram is a more formal description of the Request-Response system which indicates the major players and the relationships between them.
| Interface | Description |
|---|---|
| AbstractService | An operation |
| Request | Requested operation |
| Response | Result of an operation |
| KVPReader | Provides input to a service from an http query string |
Abstract Service
First off, this interface is poorly named. At the code level, an AbstractService really maps to an operation of a service. So this interface would better be named AbstractOperation. Keeping the distincation in mind and looking at a service implementation such as WFS we find an implementation of AbstractService for each operation defined. This is depicted in the following class diagram.
Each "service" is responsible for the following:
- Handling a particular operation
- Creating an object capable of reading the paramters of the operation
- Creating the appropriate response to the operation
Request
This interface is the representation of the operation being performed. It is mostly just a data object which contains information about the request such as:
| service | The service being called, (WFS,WMS,...) |
| request | The operation being performed, (GetCapabilities,GetFeature,...) |
| version | The version of the service implementation |
Similar to the AbstractService class, we see an implementation of Request for each operation:
KVPReader
In GeoServer a service is explicity bound to the HTTP protocol. For this reason it is natural to specify parameters to an operation as key-value pairs in the query string of a http url. For example, http://geo.openplans.org/geoserver/wfs?service=WFS&request=GetCapabilities&version=1.0.0 specifies three parameters: service,request/operation, and version.
As before we see an implementation of KVPReader for each operation of a service.
Each KVPReader is responsible for reading parameters specific to a particular operation, and parsing those values into objects.
TODO: example here.
These "parsed" parameters are then used to carry out the operation.
Response
The Response is the object that actually does the work and carries out the operation. The following table maps the responsiblities of a Response to the lifecycle methods on the interface.
| Responsiblity | Method |
|---|---|
| Carry out the operation | execute(Request) |
| Generate a response for the client | writeTo(OutputStream) |
org.geoserver.png (image/png)
org.geoserver.wfs.png (image/png)
org.geoserver.wfs.request.png (image/png)
org.geoserver.wfs.response.png (image/png)
RequestResponse.PNG (image/png)
org.geoserver.wfs.kvp.png (image/png)
